home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Gold Collection
/
Software Vault - The Gold Collection (American Databankers) (1993).ISO
/
cdr12
/
v93n05x.zip
/
V93N053.IBM
< prev
Wrap
Text File
|
1993-05-12
|
28KB
|
694 lines
24-Apr-93 13:09:41-MDT,27657;000000000000
Mail-From: GHICKS created at 17-Apr-93 17:30:36
Return-Path: <INFO-IBMPC-REQUEST@wsmr-simtel20.ARMY.MIL>
Message-ID: <930417095403.V93N53@wsmr-simtel20.Army.Mil>
Date: Sat, 17 Apr 93 09:54:01 GMT+0
From: "Info-IBMPC Digest" <Info-IBMPC@wsmr-simtel20.Army.mil>
Reply-To: Info-IBMPC@wsmr-simtel20.ARMY.mil
Subject: Info-IBMPC Digest V93 #53
To: "Info-IBMPC Distribution": ;
Info-IBMPC Digest Sat, 17 Apr 93 Volume 93 : Issue 53
Today's Editor:
Gregory Hicks - Rota Spain <GHICKS@wsmr-simtel20.Army.Mil>
Today's Topics:
Rebooting from Batch Files
Archie search (was: re:Re: PKZIP 2.04)
Info wanted on Barcode Readers
Disk compression programs
EMM386 Exception Error #0
mouse 8.02
Mouse problem
MSDOS 6.0 Problems
Need moon phase calculator
PKZIP 2.04
Programing DMA under Windows
Rebooting from BATCH files on a fast '386 (2 msgs)
Sound Source Audio Card
STACKER + DJGPP
Why is MS-DOS stuck with 640 K? (3 msgs)
WSMR-SIMTEL20.Army.Mil archive switches to ZIP 2.0
486 with SoundBlaster
Send Replies or notes for publication to: <INFO-IBMPC@brl.mil>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to: <INFO-IBMPC-REQUEST@brl.mil>
Archives of past issues of the Info-IBMPC Digest are available by FTP
ONLY from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
----------------------------------------------------------------------
Date: Tue, 6 Apr 1993 7:36:04 -0700 (PDT)
From: "RONALD W. FRYE" <FRYE@lll.llnl.gov>
Subject: Rebooting from Batch Files
Dear Netters...
Here is a problem to which I issue a challange...that you PC experts
take this one on, and try to solve it. It'll leave you scratching your
heads. I'm to the point of near insanity, turning to you for help or
advice.
HOW IT NORMALLY WORKS...
On many, many systems, I've installed and used a menu, 3DMENU to be
exact, (that creates DOS batch files) for running all programs. No
knowledge of DOS is needed by the end-user, all DOS tasks being done
from within the batch files the menu created and runs. This works
quite well, especially where other tasks must be done before running
certain programs, such as copying a special CONFIG and AUTOEXEC file,
(to CONFIG.SYS and AUTOEXEC.BAT), before rebooting the machine. The
process is totally transparent to the user, even the reboot. When the
user exits the program he wanted to run, the process is repeated,
except this time the normal CONFIG and AUTOEXEC files are copied to
CONFIG.SYS and AUTOEXEC.BAT before the machine is once again
automatically rebooted, placing the user back in the menu where he left
it before running the desired program.
The above process has worked on XTs to 386s, without a hitch, using
almost all versions of DOS, including DOS 5.0.
NOW THE PROBLEM...
I've come across a very fast 386 where the above process works only
some of the time, but not all of the time! As the batch file executes,
DOS reports that each of the two files were copied, but when the
machine reboots, it's the old CONFIG.SYS and old AUTOEXEC.BAT files
that execute, placing the user back where he started. At other times
only one of the correct files was copied before the machine did a
reboot. And yet other times both files were copied, placing the user in
the desired program.
Upon exiting the desired program, the same thing happens, DOS reporting
that two files were copied, but when the machine reboots, only one or
none of the new files was copied.
SOME ADDITIONAL INFO...
The program that reboots the computer is called REBOOT, that comes with
the VPIC series of graphics programs.
I've also inserted a delay in the batch files, which comes after
copying each of the CONFIG and AUTOEXEC files, and before the reboot,
using a program called WAIT, also from the VPIC series. I've waited up
to 2 seconds, which seems to improve the situation, but not cure it
entirely.
One of the programs requires some expanded memory, and this is setup
from the batch files described earlier. It's a pretty simple matter to
set up extended memory to emulate expanded memory using DOS 5.0's
EMM386, but DOS 5.0's EMM386 will not set it up, whereas QEMM386 will!
Any idea as to what's going on? I'm at my wits end. PLEASE HELP IF
YOU CAN! I can be reached at the following addresses:
at work... frye1@llnl.gov
at home... ronfrye@aol.com
Thanks,
Ronald W. Frye
------------------------------
Date: Tue, 6 Apr 93 14:32:06 TUR
From: "P. Rovers" <PROVERS@KUB.NL>
Subject: Archie search (was: re:Re: PKZIP 2.04)
> Bill or anyone.
> Could you please tell me how to do an archie search?? I really need some
> programs and would like to save my phone bill. Thanks Terry
>
If you can use telnet, try 'telnet archie.au' (australia) or 'telnet
nic.funet.fi' (europe) or 'telnet archie.rutgers.edu' (USA). Login as
'archie' and try 'help'.
If you can only use e-mail try a mail to archie@cs.mcgill.ca with body
'help'. If you want to ftp thru mail, send a mail to
bitftp@pucc.princeton.edu with body 'help'.
PkZIP 2.04g can be found on several sites including nic.funet.fi and
garbo.uwasa.fi in directory pub/arcers I believe.
Hope this helps,
|Perry Rovers, Faculty of Economics/Econometrics (KUB/FEW) |
|Tilburg University (KUB), The Netherlands |
|Internet: provers@kub.nl
|Bitnet : PROVERS@HTIKUB5
|DECNet : KUBVX1::PROVERS
------------------------------
Date: Sun, 4 Apr 1993 20:58 CDT
From: Gary Rodman <RODMAN@ariel.ripon.edu>
Subject: barcode readers
I am interested in purchasing a barcode reader for our campus
bookstore to use with its Point of Sale software (Real World). How do
these things work? Are they serial devices or do they plug into the
keyboard port? We would like a "gun" type, rather than a wand so that
the thing is easy to use and quick. Where can I get information about
these things? What are the good brands??
We have a 386 clone....
thanks...
- Gary
Rodman@admin.ripon.edu
Gary Rodman, Ripon College
------------------------------
Date: Sat, 03 Apr 93 09:25:09 EST
From: Alan Schick <RAMSPEC@vtvm1.cc.vt.edu>
Subject: Disk compression programs
I have a number of "need to be upgraded" computers with 20, 30, and
40Mb hard drives in them.
For financial reasons they will be upgraded or replaced slowly, so in
the mean time I am looking for a low-cost alternative to getting larger
HD's -- i.e. a disk compression program. I have seen mention of
several, primarily Stacker 3.0, DoubleDisk Gold and that included with
DOS 6.0, but have not seen any decent comparisons between them...so I
am interested in any feedback from people who have experience and/or
opinions on the subject.
And regarding the compression routines included in DOS 6.0, does it
matter which (PC vs. MS vs. DR) DOS one is dealing with? Simple
"thumbs up" or "thumbs down", as well as more detailed replies, are
appreciated. I will tabulate and post the
------------------------------
Date: Tue, 6 Apr 93 08:48:17 GMT+7
From: "Douglas R. Nebeker" <$DOUGN@SASB.BYU.EDU>
Subject: EMM386 Exception Error #0
I'm trying to write a small device-driver type program that must get
loaded before EMM386. When EMM386 loads, it gives me a EMM386
Exception Error #0. Does anyone know what this error means, how it is
caused, or where I can look for further info???
Thanks
Douglas R. Nebeker Internet: $dougn@sasb.byu.edu
Brigham Young University
------------------------------
Date: Wed, 7 Apr 93 12:46:18 DNT
From: Jan brentved <USIJB@VM.IBT.DK>
Subject: mouse 8.02
Not only MICROSOFT MOUSE uses quite a lot of memory. Compared with
other products with greater abilities. As seen below in cuts from
different system configuration. Other faster (ansi.com) or enlarged
products (4DOS) does not need to use more memory than standard dos.
Why, I'm like to know.
Memory Info V7
(c)1991 Central Point Software, Inc.
Total bytes owned
Addr. Low area High area Program or device driver
----- -------- --------- --------------------------
>MICROSOFT MOUSE
03EAh 14,976 .. MOUSE
>TRUEDOX Technology Corporation MODEL 300 VER. 4.00 Copyright 1987-1992
F450h .. 8,960 MOUSE C:\CONFIG\MOUSE.COM
>MICROSOFT COMMAND.COM
0D65h 3,024 .. COMMAND
>4DOS.COM (Include all doskey functions 4,128 byte, and MANY enlargements)
03D3h 256 .. 4DOS
D595h .. 3,184 UMB C:\4DOS\
>MICROSOFT ANSI.SYS
F405h .. 4,192 Device=ANSI Attr=C053h Name=CON
>PC MAGAZINE ANSI.COM ANSI 1.32 (C) 1988 Ziff Communications Co.
03F3h 2,576 .. ANSI
Note:
ansi.com+4dos.com+mouse=14,976 = memory used by one microsoft mouse.
Jan Brentved
usijb@vm.ibt.dk
------------------------------
Date: Tue, 6 Apr 93 16:52:00 CDT
From: PSYCRSS%OSUCC.BITNET@FRMOP11.CNUSC.FR
Subject: Mouse problem
I have been using Telemate for some time in DOS, but I recently
began running it under Windows.
It works fine if I run it in a full screen, but when I try to run it
windowed, I end up with two mouse pointers. One is the arrow pointer
you see in Windows, and the other is the block pointer seen in
Telemate. I recently installed a mouse driver for Qedit, and I have
the same problem. Is there any way to disable one or the other
pointer?
Bob Schlottmann
PSYCRSS@OSUCC.BITNET
------------------------------
Date: Mon, 5 Apr 93 6:49:18 PST
From: " Page Carter (Network Solutions" <rcarter@gizmo.nic.ddn.mil>
Subject: MSDOS 6.0 Problems
One problem with upgrading too quickly to new software is that you
become a victim of bugs. There appears to be a major problem with the
new MSDOS 6.0 version of EMM386. When c:\dos\emm386 is loaded in my
config.sys, Windows and other programs lock up. When I run Norton's SI,
it claims I have Hercules video, with Hercules secondary. (I have VGA!)
If I instead load C:\windows\emm386, everything works as it should, and
SI says I have VGA. Well, if you try to optimize memory using the new
memmaker, it insists on putting the dos version of emm386 back in
config.sys!
Another observation: I don't have nearly as much free memory with DOS
6.0 as I did with DOS 5.0. That is causing problems with other
programs. I have yet to find a configuration that will let me run
Geoworks. I have even added it to the SETVER list, just in case.
One plus is the disk compression. I went from 16 meg free to 64 meg!
However, I am sorely tempted to revert to MSDOS 5.0, if Microsoft
doesn't come up with some solutions quickly. (Some of my fellow workers
are saying "I told you so.)
Incidentally, a quick glance at the MSDOS Forum on CompuServe reflected
my complaints.
Otherwise, have a nice day. :-) Page Carter
------------------------------
Date: Tue, 6 Apr 93 10:29:24 EDT
From: Robert=J.=Haehnle%FMD%PGAS@crow.nist.gov
Subject: Need moon phase calculator
Does anyone know of a shareware or freeware program to calculate moon
phases. I've tried several of the programs on SIMTEO-20 (Astronomy
sub-directory) but have had no luck finding the 'right' one yet.
Thanks.
____________________________________________________________________
|Robert J. Haehnle |Internet: BobH%FMD%PGAS@CROW.NIST.GOV|
|National Oceanic & Atmospheric|OMNET: R.HAEHNLE |
| Administration, OA-34 |MCI: 297-0105 |
|< ALL OPINIONS EXPRESSED ARE MINE - NOT NOAA'S NOR US GOVERNMENT'S >|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Tue, 6 Apr 93 14:38:16 TUR
From: "P. Rovers" <PROVERS@KUB.NL>
Subject: PKZIP 2.04
> As I understand it, SIMTEL-20 is dropping the PKZIP products due to the
> export restrictions of that product. New uploads will be using INFO-ZIP
Yep.
> groups unzip and zip utilities. So, *.zip files can now have 3 formats.
Yep.
> (1) The older version 1.10 ZIPS that used to be the standard, (2) The
> version 2.04x ZIP format for the newer uploads at some sites, and (3)
> INFO-ZIP's format for uploads to SIMTEL-20 and its mirrors.
Also the 1.93 and 2.01 (1.93b) versions of PKZIP seem to differ and
there are also ZIP files around created by PKZIP 1.01 and 1.02.
In the STARTERS directory on simtel there's a .EXE file for MS-DOS
which is just what you need if you don't want to know more about the
whole archiving business, but just want to unzip :-)
BTW there were a lot of reports about the 2.0x versions being buggy
when using XMS or EMS. This appears to have been solved in the 2.04g
version so try to get that one. I never had any problems but some
people lost valuable data using the first 2.04
Hope this helps,
|Perry Rovers, Faculty of Economics/Econometrics (KUB/FEW) |
|Tilburg University (KUB), The Netherlands |
|Internet: provers@kub.nl
|Bitnet : PROVERS@HTIKUB5
|DECNet : KUBVX1::PROVERS
------------------------------
Date: Wed, 7 Apr 1993 16:50:52 -0500
From: mendel@bit.csc.lsu.edu (Gili Mendel)
Subject: Programing DMA under Windows
I am using TC++ 3.1 for Windows. I was trying to program my hand held
scanner (GeniScan GS4500). I could do it with DOS. The problem arises
from the fact that one has to program the DMA (direct memory access).
To do this, one has to know the physical (actuall) address of the DMA
buffer. Under DOS, when one perform malloc() the address of the buffer
is actual address.
How could I get the actuall address if I am using GlobalAllocPtr ()
under Windows ? Or how one goes about setting the DMA addressing under
windows ?
Thanks,
Gili
mendel@bit.csc.lsu.edu
------------------------------
Date: Tue, 6 Apr 93 17:31:44 EDT
From: Gregory Hicks - Rota Spain <ghicks@BRL.MIL>
Subject: Rebooting from BATCH files on a fast '386
Ron:
Although I really don't know everything you've tried...
I ran up against the same problem a little while ago (regarding
rebooting). I had a batch file that copied one CONFIG.NOL to
CONFIG.SYS and then rebooted. Another copied CONFIG.LAN to CONFIG.SYS
and then rebooted.
I found that the problem was caused by SMARTDRV (or the equivelant if
you're not using that one) delaying writes to the hard disk for some
fraction of a minute. I solved the problem by inserting a PAUSE
command in both batch files. This gave the disk write time to
complete.
I've since found that you can do the same thing by issuing a reset
command to SMARTDRV (ie: the /C /R switches) and then doing the reboot
command
from the batch file. (Not too sure which one it is, just that now it
works...)
Investigate and pick your solution. YMMV (Your milage may vary...)
Regards,
Gregory Hicks
------------------------------
Date: Tue, 6 Apr 1993 15:38:40 -0700 (PDT)
From: "RONALD W. FRYE" <FRYE@lll.llnl.gov>
Subject: Rebooting from BATCH files on a fast '386
Greg...
I sure didn't expect such a quick response to my query...I'll sure give
it a try. Thanks a million! It will be interesting to see what the
rest of the P.C. Gurus out there come up with also.
Ron Frye
------------------------------
Date: Tue, 6 Apr 93 9:44:10 EDT
From: "Jesus A. Sanchez" <jsanchez@pica.army.mil>
Subject: Sound Source Audio Card
I have a Sound Source Audio card for IBM PCs and compatibles. Walt
Disney games use this card for sound and speech. This card is
connected to the computer through the parallel port. I am interested
in obtaining information on how to program this audio card. The
board's circuit is simple and it uses one chip labaled ICS 1453. I
tried looking it up in the IC Master, but it was not listed. I will
appriciate any information I can get on this matter.
Thank you all in advance.
Jesus Sanchez
Email: jsanchez@pica.army.mil
------------------------------
Date: Wed, 7 Apr 1993 04:23:16 GMT
From: junaid@monu6.cc.monash.edu.au (Mr A. Walker)
Subject: STACKER + DJGPP
I have a problem with djgpp (GCC 2.2.2 for DOS), the latest
version. When i run gcc on a Stacker drive, stacker complains 'Read
error' and after pressing Ignore, it continues OK. This also happens
with the program DISP125 which the author compiled with djgpp.
Obviously there are no bad sectors on my IDE drive, as this is
the only time i get these spurious 'read errors'. Also when i install
these programs on a non-stacker drive all goes well.
My suspicion is that there is an incompatibility between go32
and stacker while it is bootstrapping the 32-bit exe.
Does anyone else have this problem or a fix for it so that i
can run go32'ed programs on a Stacker drive?
Just for reference, i have a AMD386-33, DOS5.0, QEMM-6.02 .
------------------------------
Date: Tue, 6 Apr 93 14:54:12 EDT
From: Tom Frenkel <FRENKEL@CPMAIL-AM.CIS.COLUMBIA.EDU>
Subject: Why is MS-DOS stuck with 640 K?
Hi ... this question has been bothering me: It is common knowledge
that one of the basic deficiencies of MS-DOS is that it cannot, on its
own, handle programs in excess of 640 K (or thereabouts). BUT... why
hasn't Microsoft ever simply upgraded DOS so that the allowable memory
size was greatly increased? There MUST, I would think, be some
enormous stumbling block in the way of such a step ... but I wouldn't
know what it would be. Just think of the new interest that MS-DOS
would generate if it could easily handle memory spaces of, say, 20
megabytes!
Can anyone out there satisfy my curiosity? Thanks!
Tom Frenkel (frenkel@cpmail-am.cis.columbia.edu)
------------------------------
Date: Wed, 7 Apr 93 10:26:00 EDT
From: John Mertus <MERTUS%BROWNVM.BITNET@FRMOP11.CNUSC.FR>
Subject: Why is MS-DOS stuck with 640 K?
I can answer part of the question, one of the PRIME drives behind MS
DOS is binary standards.
I've have some programs that were written in compilied basic under DOS
1.1 that still work under 5.0 without recompiling. IBM wanted people
to upgrade machines NOT programs. (Didn't really work that way.) To
keep this standard, required some memory standards to be worked out.
DPMI (Dos Protected Mode Interface) is one of them.
Using this one writes programs up to 16MEG that run under standard DOS.
(PharLap, Turbo Pascal 7.0, Intel are three examples.) This is how I
program now and it all works fine. But as all standards, it took a
long time coming. IBM could have solve it all in three months had they
introduced one BUT IBM wants people to run OS/2 and did not want a
better DOS, Microsoft wants people to run windows, they don't want a
better DOS. As usual, Microsoft and IBM do what is best for corporate
profits NOT for the consumers. Thank God for Borland, DR DOS, without
that competition, we would be mired in DOS 3.2 with 1984 class
compilers....
-John"Not a fan of Bill Gates"Mertus
------------------------------
Date: Wed, 7 Apr 93 11:45:22 +0200
From: Jac Goudsmit <S89406316@HSE.NL>
Subject: Why is MS-DOS stuck with 640 K?
In message of 06 Apr 93 14:54:12 -0400 (EDT), Tom Frenkel said:
>... stumbling block of 640 K?
>[...text deleted...]
The "enormous stumbling block" is the video display RAM and the BIOS.
The original PC and PC/XT had an 8088 processor, as you probably know.
That processor can only access 1 MB of memory. The general memory map
of the PC(/XT) (let's say at the moment that it starts loading DOS or
any other operating system) is like this (I won't bother you with the
addresses and with memory segmentation):
+--------------------------+ <--- 1024KB=1MB address space border for 808x
| BIOS |
| 16KB in the IBM-PC(/XT) |
| 128KB in most PC's now |
+--------------------------+
| (space used for EMS |
| page frame and BIOS |
| extension ROMs such as |
| the hard disk BIOS and |
| VGA BIOS) |
+--------------------------+
| Video display memory |
| (even if you have a VGA |
| with 1MB of memory, only |
| 128K can be seen by the |
| PC at once. The MDA and |
| CGA have much less |
| memory. |
+--------------------------+ <--- 640KB
| RAM for programs & data |
+--------------------------+ <--- a little over 1KB
| interrupt vectors & BIOS |
| data storage area |
+--------------------------+ <--- 0KB
(The sizes of the blocks as they are drawn here are not proportional to
their actual size)
What the newer Intel processors do if you run DOS, is emulate the
8086/8088 memory space. This means the memory map is exactly the same
as above, including the 1 Meg address space. The programs that run on
an 8086/8088 just can't address more - the program is in the way the
assembler instructions are coded. (Don't flame me because of that last
remark, I know it's a bit inaccurate). And because display memory and
BIOS are in the way, the last 384KB of address space cannot be used for
RAM either.
In their native mode ("protected mode") however, the 80286, 80386,
80486 and 80586 (note that I refuse to call it Pentium :-) can address
much more memory (several Gigabytes; 1GB is 1024MB, or 1048576KB), but
DOS won't work then because memory addressing works differently in
protected mode.
So what IBM has done is to make some functions into the BIOS of the
PC/AT to switch to protected mode, access the large memory space, then
reset (literally) to real mode (emulating the 8086). This is now called
extended memory. (There are other ways to use extended memory, but I
won't go into that)
Furthermore, the 80286 has a bug (or was it a feature) in it that
permits the PC to use the first (almost) 64K of extended memory. This
is because with a trick you can make the processor _calculate_ an
address above 1MB, where the 8086/8088 would wrap around the 1MB
border. That 64K of memory is called the High Memory Area (HMA).
Because 1 MB RAM chips are getting cheaper, most PC manufacturers use
them even for the area below the 1MB border. That means that any unused
space between the video display memory and the BIOS ROM is now RAM, and
is available to store data and programs. The pieces of memory here are
called Upper Memory Blocks (UMB).
With DOS version earlier than 5.00, you could only use conventional
memory to store the DOS kernel, device drivers and programs. With DOS
5.00 (and up, I presume), you can store the DOS kernel, device drivers
and resident programs in the UMB or HMA, by giving the correct commands
in CONFIG.SYS. That way you have more memory free for normal programs
that don't know about this "new memory". To them, DOS pretends the
extra memory doesn't exist. Most programs nowadays know how to access
the extended memory and use it. To older programs that don't bother to
ask, DOS still has its 640K limit.
Jac Goudsmit |
Student, Information Technology |
Hogeschool Eindhoven, The Netherlands |
(Eindhoven Polytechnic) |
S89406316@HSE.NL |
Earn/Bitnet: S89406316%HSE.NL@HEARN |
------------------------------
Date: Sat, 3 Apr 1993 19:30:45 GMT
From: Keith Petersen <w8sdz@tacom-emh1.army.mil>
Subject: WSMR-SIMTEL20.Army.Mil archive switches to ZIP 2.0
A SIMTEL20 user writes:
> You're surely not going to reZIP all the old files?
No. Old ZIP files will remain as-is. All old ARC files will
eventually be converted to ZIPs.
> Is this new ZIP backward compatible? Or do we need to retain two
> versions of ZIP?
The new UNZIP and ZIP are backwards compatible. You do not have to
keep old versions.
> I just downloaded from garbo a PKZIP v 2.04g. I assume that this
> is the non-exportable version?
It is the version which is non-exportable to countries on the
restricted list. It was uploaded to garbo by PKWare.
> Which of the ones do you mean by ver 2.0.
Any version which supports the ZIP 2.x file format. SIMTEL20 offers
the Info-ZIP group's freely distributable UNZIP and ZIP. They are
compatible with PKUNZIP v2.04g.
Directory PD1:<MSDOS.ZIP>
Filename Type Length Date Description
==============================================
UNZ50P1.EXE B 40062 930119 Info-ZIP's free portable UNZIPv5.0p1, EXE/docs
UNZ50P1.ZIP B 240282 930115 C src code for free Unix/VMS/MS-DOS/etc. UNZIP
ZIP19P1.ZIP B 202085 920830 Info-ZIP portable ZIP v1.9, patch level 1, src
ZIP19P1X.ZIP B 114278 920830 Info-ZIP portable zip 1.9, patch level 1, EXEs
> Maybe there is a development that I missed. What is the public domain
> version of ZIP which seems to have come from some org named Info-ZIP?
The ZIP file format is public domain. The Info-ZIP programs are not
public domain. They are free, freely distributable, and come with
source code.
Info-ZIP is the name of the mailing list of the developers of portable
UNZIP and ZIP. The addresses for subscribing to their mailing lists
are:
Developer's discussion: Info-ZIP-Request%wkuvx1.bitnet@ukcc.uky.edu
Anouncements only: Info-ZIP-Announce-Request%wkuvx1.bitnet@ukcc.uky.edu
> Is this an independent development that happens to be able to handle
> PKWARE's newer file formats?
Yes.
Keith
--
Keith Petersen
Maintainer of the MS-DOS archive at WSMR-SIMTEL20.Army.Mil [192.88.110.20]
Internet: w8sdz@TACOM-EMH1.Army.Mil or w8sdz@Vela.ACS.Oakland.Edu
Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
------------------------------
Date: Mon, 5 Apr 93 09:13:21 +0200
From: bermn@birisc.cs.biu.ac.il
Subject: 486 with SoundBlaster
Hi subscribers!
I have a problem using a Sound Blaster with MS Windows on 486 DX50. I
has a 386 and it was fine. Now I made an upgrade to 486 and some
strange thing happened. When I run Windows and Control Panel I see that
System Sounds are disabled. When I try to play some .WAV file, it
doesn't plays. Other sounds like .MID are OK. I installed and
re-installed Windows and SB drivers from original disks , but with the
same result. All diagnostics like NDIAGS and ANSI benchmark reports OK.
I have checked all jumpers, IRQ's. Does it means that some drivers
especially for 486 are requers?
These are my system settings: 486 DX50, Sound Blaster 2.0 on IRQ 5,
address 240, DMA 1, and standart MS Windows 3.10, DOS 6, QEMM 6.03,
Trident SVGA 1024 in Windows is 800x600x256. Thanks in any advance,
Moby.
P.S. When I installed DOS 5 with HIMEM, there was a same problem
------------------------------
End of Info-IBMPC Digest V93 #53
********************************
-------